Open GitHub CLI Accessible Experiences Public Preview

[queenofcorgis]

We’ve introduced new accessibility updates to the GitHub CLI, designed to make terminal workflows more inclusive for all developers. These improvements focus on:

• Speech synthesis screen reader support: Enhanced prompting and progress indicators now provide better context and clarity for users relying on screen readers.
• Color and contrast customization: Optimized color palettes ensure compatibility with terminal preferences, maintaining readability for users with low vision or colorblindness. Alignment with ANSI 4-bit color standards allows users to tailor their color usage to their needs.

These updates are available in public preview. To start using these features, run gh a11y.

To learn more, check out the GitHub CLI release notes for version 2.72.0.

You can view all avenues for GitHub accessibility feedback on our webpage.

[jscholes]

Really happy to see this happening! Some comments:

Firstly: the Building a more accessible GitHub CLI blog post includes four audio samples of screen reader output with no transcripts or captions. Deafblind braille users will just encounter four random audio players without context as to why they've been included.

Secondly: when I run gh a11y, I get output like:

  # Use input prompts without redrawing the screen
  $ gh config set accessible_prompter enabled

Note the indentation before both of these lines, and the $ sign before the command. It would be easier to copy the commands for pasting if neither the indentation nor dollar sign were present.

Thirdly: I'm really glad that these improvements have been implemented as standard config options, rather than users needing to opt into an "accessible mode" or something like that.

However, I note that two of the settings (accessible_colors and accessible_prompter) include "accessible" in their names which feels a bit othering and quite vague (what is "accessible prompting" to someone who hasn't tried it or read the blog post?). It also makes them inconsistent with the third option which is just named spinner.

I think the option names could be updated to not mention accessibility, and be more informative. E.g. numeric_promptss and customizable_colors.

And finally: in a few places you refer to "Speech synthesis screen reader" (which is a kind of awkward, uncommon phrase), but the changes you're making improve things for braille users too.

Thanks for all the work that's going into this!

[andyfeller]

Thank you for taking your time and helping us improve the GitHub CLI, @jscholes! 🫶

First, my sincere apologies about the blog post audio samples. I am working with our Blog and Accessibility teams as I've re-recorded the audio samples with a narrated script; we're working on getting the captions added and will update them.

Second, your feedback on the gh a11y example format is something I can raise up with maintainers as this is the format for examples on any gh command. Personally, I could see the terminal prompt indicator ($) removed all together. Again, I would like to address this holistically rather than an inconsistent experience.

Third, I would like to discuss this further to understand alternative configuration setting names.

Configuration setting names have been a recurring topic for a number of reasons:

• how fine grained should a given setting be?
• how do we clearly yet simply explain the effect of a setting?

Truthfully, I think this is a research opportunity as there are few CLIs that have documented their accessibility journey and how they address many of these concerns. One example we discovered was gcloud uses gcloud config set accessibility/screen_reader true to enable multiple effects.

Part of the effort in this public preview is to work with our community to balance these and other concerns while figuring which of these should be a out-of-the-box experience.

In the case of accessible_colors, other alternatives were ansi_colors, 4bit_colors, customizable_colors, and more. However, terminal users might not understand these technical terms and it also focused on the technology rather than the effect.

In the case of accessible_prompter, there was a lot of back and forth because of what is technically being done with this new dependency. Previously, gh prompting experience would act like a text UI that redrew parts of the screen when users were prompted. The aim is making user prompts easier for speech synthesizers and braille readers to detect and communicate. Would noninteractive_prompter be better?

Really open to ideas 🙇

[andyfeller]

And finally: in a few places you refer to "Speech synthesis screen reader" (which is a kind of awkward, uncommon phrase), but the changes you're making improve things for braille users too.

I would greatly appreciate guidance on more commonly used terminology! 🙌

Through this journey, we have come to appreciate the "screen reader" is a broad category and that these changes can benefit both text-to-speech and text-to-braille use cases. The primary challenge being we want to work with our users with lived experiences before we make such claims.

It is my hope the GitHub CLI maintainers in collaboration with GitHub's Accessibility Discussion Panel can find clear and simple language we can consistently use.

[n0ot]

I haven't thought about how this could be solved yet, but the accessible prompter doesn't allow you to filter choices by a substring. I frequently edit labels in pull requests by typing part of their name, and then space to check or uncheck the one that matches, or when running workflows, I'll type enough of the workflow name to limit the choices such that I don't have to do much (or any) scrolling with my screen reader to find the one I want to run. I could, of course, memorize the numbers, but then someone might add or remove a workflow or label, so I feel like I would have to review more of the screen to be sure I'm making the right selection.

The [ ] (unchecked) and [x] (checked) indecators read better with my screen reader/punctuation settings than the presence or lack of a ✓ (which is what you get with the accessible prompt). I could account for that by adjusting my punctuation settings, but it might not be obvious to everyone.

[andyfeller]

Thank you for taking the time to opt-in to the public preview and share this feedback, @n0ot! 🫶

First, I think your point on reducing the cognitive load and effort on selects and multi-selects is an important concern. 🤔

• should the new prompting experience support a fuzzy finder experience, allowing users to enter a partial term to refine further?
• do users need an option to repeat the prompt or actions?

I would appreciate any thoughts you might have including any other CLI experiences we can examine! 🙇

This would allow us to continue the discussion with our friends at Charm, who created charmbracelet/huh in collaboration with us to supersede a previously maintained module. 🦸

Second, thank you for feedback on typography! This is an area I would love to expand on further across gh with you and others on GitHub's Accessibility Discussion Panel. All of that said, let me see what we can do regarding this.